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EBQCESS MAMAf?FMF|v|T c Y °TFM 

The present invention relates to process management systems. It finds 
particular application in the provision of services over a communications network. 
5 with particular reference to feature interaction. 

There are many processes which are complex and which can be carried 
out ,n more than one way. Embodiments of the present invention are intended to 
select and configure the steps in a process. 

An example of a complex process, which can be controlled by a 
10 management system according to an embodiment of the present invention, is that 
of service provision over one or more communications networks. Recently the 
services available to users over communications networks have grown much more 
sophisticated. For instance, in the UK, it is now possible to subscribe to call 
waiting and answering services, provided over the public switched 
15 telecommunications network (PSTN), ft is expected that modernisation of existing 
networks, and the provision of new networks, will lead to a proliferation of new 
services. 

Increasingly in the future, different types of services are likely to be 
offered over communications networks. For instance the increasing capability of 
20 technology is enabling a future where a wide variety of mu.timedia services can be 
delivered to users over communications networks. These services could include 
s.mple voice telephony, multimedia conference amongst many users, home 
shopping and video on demand. Additionally users may want such services to be 
delivered over a variety of terminal types such as a portable phone, portable 
25 personal computer and domestic television set with a set-top-box. 

These services come not only from development of the 
telecommunications environment, including telephony and cable television, but 
also from environments previously separate, such as the computing environment 
For .nstance. there has been major growth of computer network services, such as 
30 those available on Internet. Col.ectively al. these services are referred to herein as 
information services. 

Although to date (at least in the telephony wor.d> the communication 
network operator and the service provider (SP) have generally coincided, this is not 
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essentia.. Another trend expected in the future is that, increasing, the service 
provider wil. be separate from the network operator. As in the case of .nternet 
severai SPs [vendors, may offer their services (products, over a common network' 
indeed, there may be further comp.exity involved in that the "common network" 
5 m.ght in fact comprise multiple networks connected together, managed by many 
different network providers. 

Communications services are based on functionary provided by the 
networks carrying the services. , n tne telecommunications arena recent 
deve.opments mean that this could be provided increasing by intelligence, ie 

10 decs.on-making software, in an inte.ligem network architecture. With the 
convergence of computing and telecommunications technology, however, 
functionality may in practice be provided in other ways. 

Regardless of how functionality will be provided, there has emerged a 
prob.em of "feature interaction". This arises for instance when features which 

15 would normaHy be triggered in provision of one service, conflict with features 
normal.y triggered in provision of another service and the two services are ca..ed 
on at the same time. A simple example of feature interaction is the conflict 
between "Call Forwarding" and "Call Waiting". Clearly a call cannot be both 
forwarded and kept waiting. 

20 As services grow more diverse, feature interaction has been found to be a 

very complex problem. It is considered one of the fundamental obstacles to rapid 
development and deployment of new services. As the number of new features 
grows, the time required to introduce them grows. 

In attempting to solve the feature interaction problem, a strategy has been 

25 to classify the solutions into avoidance, detection and resolution. Avoidance looks 
at ways to prevent undesired feature interactions. Detection assumes that feature 
-nteractions will be present, and determines methods for identify.ng and locating 
them. Resolution assumes that feature interactions wil. be present and detected 
and looks at mechanisms for minimising their potential adverse effects It is not 

30 practical to assume that the so.ution can be provided by just one approach 
Feature interactions found before deployment can be avoided. In contrast, feature 
-nteractions detected during run-time must be reso.ved at run-time. One advantage 
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of ,un-„me inaction resolution is tna, ,„e problem space is reduced, since o„, y 
,nf„rma,io„ specific ,„ each occurrence of an in.erac.ion need be considered 

Curren, approaches to ru„-,ime reso,„,i„n inciude even, based resoiution 
and negotiating software agems Even, based ,eso,u„o„ is based on an approach 
5 of costing events during the basic cal, process which trigger ,he activation of 
features. ,„ this way. the feature manager can control which features shouid be 
invoked. These approaches can resofve issues such as signal ambiguities and 
incompatible combinations of call-proeessing activities. An alternative approach is 
to use nego„a,ing software agents proposed by Griffeths and velthuiisen in -The 
10 Negotiate Agents Approach to Runtime Feat(Jte , nterac , |on 

PUb,ished in ,994 by ,0S Press. This approach uses agents ,o represent users' 
network providers, and terminals, collecively ca»ed entities. Users define policies 
wh,ch describe how each feature should behave. These policies constrain the se, 
o, operations ,h„ each user „, provider is wining ,„ perform i„ i nit i a ,i„ g or 
'5 modifying , ca». A negotiation mechanism is used to resolve conflicts between 
the policies of different users, thus maintaining autonomy amongst the users 

In this description the term -agent" relates to a function or process which 
operates in , computing environment and which can ac, autonomously to receive a 
request for an operation and provide a result. An .gen, normally has an up-databl. 
20 dat, store for hoiding d„a relevant ,„ local conditions, and us„a«y „s„ ,„, ho ,di„g 
some global information about the distributed environment in which i, si,s Agents 
operate autonomously, having decision-making functionality .intelligence, allowing 
,hem ,o negotiate and output a result in response ,o an incoming message. The 
resuit may be for instance a contro, signal to apparatus. ,n the communications 
25 environment, the comro, signal may cause a connedon ,o be made according to , 
particular configuration. 

Typicany. an agent is embodied as a p,ece of sofware. ,o, example 
wmten in ,he C programming language, running on a suitable computing piatform 
o, examp,e a UN,X (Trademark, based piattorm. Requests and results are passed 
between an agent and a requesting entrty. which might be another agen, across a 
suitable communications network. „r example a TCP/IP-based local area network 
.0 which the computing piatform is interfaced. In some embodiment, plura'l 
agems can reside on a common computing p ,a,,orm and. conversely, a single 
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agent can be realised across plural computing platforms in the environment. Also, 
the computing environment might be heterogeneous, and support various different 
types of computing platforms. 

According to a first aspect of the present invention, there is provided a 
5 method of processing data in data processing means, so as to generate an output 
signal in response to at least one input signal, wherein the input signal comprises 
at least one data element, which method comprises: 

i) storing a set of data elements; 

ii) allocating to each stored data element a weighting factor; 
0 iii) receiving said input signal; 

iv) for each data element of the input signal, searching for that data element 
in the stored set of data elements; 

v) for each data element of the input signal which is found by the search in 
the stored set of data elements, reviewing the weighting factor allocated to that 

5 data element; and 

vi) generating an output signal determined by the reviewed weighting factors. 
Preferably, there are provided at least first and second data processing 

means, wherein the input signal is received by the first data processing means 
from the second data processing means and the output signal is sent by the first 
0 data processing means to the second data processing means, said output signal 
comprising a response selected from: 

a) acceptance; 

b) rejection; and 

c) a signal comprising at least one data element. 

In embodiments of the present invention, the data processing means for a 
first entity and a second entity can make proposals and counter proposals to each 
other over the way in which a process is to be carried out. Each data processing 
means looks at its own preferences, the "weighting factors", for the elements of 
the proposal incoming from the other data processing means. If it can put forward 
a counter proposal which is more acceptable to it in the light of its own 
preferences, it will do so and wait for the other data processing means to review 
the counter proposal in its turn, against its own preferences. 
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Clearly, there will be circumstances where a data processing means 
accepts a proposa. even though it can put forward a better proposal from its point 
of view. For instance, this will happen if it has already had the "better" proposal 
rejected, or if the negotiation process has become too protracted. 
5 Processes other than communications service configuration which might 

benefit from an embodiment of the present invention would include for instance 
estabhsh.ng parameters such as costs and timing for eiectronic trading and 
transfer of funds, establishing access and download of data, and information 
filtering. 

1 0 Embodiments of the present invention are particular.y useful when directed 

to .dentifying and resolving feature interactions in communications service 
provision at runtime. 

According to a second aspect of the present invention, there is provided a 
method of estab.ishing a connection over a communications network, for service 
15 provision between first and second users of the network, there being provided 
respective connection setup means for said users, which method comprises: 

i) storing for each of said users data defining at least one connection 
configuration; 

20 

ii) storing in respect of data defining a connection configuration for the second 
user, data defining at least one alternative connection configuration; and 

Hi) storing in respect of said data defining a connection configuration for the 
25 second user, and in respect of the data defining the or each of its alternative 
connection configuration(s). a respective priority indicator; 

the method further comprising a negotiation process for the estab.ishment of a 
connection by means of: 



30 



iv) transmitting data defining a proposed connection configuration from the 
connect-on setup means for the first user to the connection set up means for the 
second user; 
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v) reviewing the data defining the proposed configuration at the connection 
setup means for the second user by accessing the data defining configurations and 
the respective priority indicators stored in respect of the second user; and 

5 

vi) selecting and transmitting a response to the connection setup means for the 
first user, the response being determined at least in part by the result of the review 
step v) above, and selected from acceptance or rejection of the proposed 
connection configuration, or comprising data defining a counter-proposed 

10 connection configuration. 

According to a third aspect of the present invention, there is provided 
apparatus for use in establishing communications connections by means of a 
communications network, the apparatus comprising: 

1 5 i) first and second network access points; 

ii) at least one data store for storing user profiles, each user profile 
comprising a set of connection configurations associated with a respective user, 
and for storing priority indicators in relation to at least two of said connection 
configurations; and 

20 iii) first and second connection set up means for use in establishing 
connections between said access points, 

wherein said first and second connection set up means are each provided with a 
negotiation protocol, access to at least one user profile in the data store, and 

25 means to review said priority indicators for that user profile, such that a 
communication connection can be set up between the access points, on behalf of 
at least two users, by negotiation between the first and second connection set up 
means, based on the respective user profiles and the related priority indicators. 

It will be seen that embodiments of the present invention allow feature 

30 interactions to be circumvented at run-time for a communications service by 
means of a user being able to preselect to abandon a service aspect in response to 
a potential compromise proposal from another user by building in an order of 
preference for service aspects. 
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Significant aspects of preferred embodiments of the present invention for 
use in communications service provision are: 

• the introduction of scheduling so that an otherwise failed connection can be 
5 reattempted 

• the provision of a preference order for connection configurations 

• a negotiation strategy which can be varied both in general terms and specifically 

for each user 

• the facility to send multiple connection configurations between users, and the 
1 0 negotiation protocol offered 

• the representation of features as high level goals, 

• how these high level goals are mapped into a user configuration, and 

• the way in which agents, acting on behalf of the users involved in any given 
connection, negotiate in the connection setup process. 



15 



Although embodiments of the invention are clearly very useful in 
communications service provision, as described above, they can also have 
application in a wide range of process environments. Wherever there is a choice in 
the way elements of a process might be carried out. and wherever there are 
20 different entities involved in the carrying out of the process, which entities may 
have different preferences, then an embodiment of the present invention may be 
appropriate. 



25 



f ERM1NOI nqy 

For the purposes of this patent specification, we will define the following 



terms: 



Feature 



30 



A feature is a tariffable unit. e.g. Call Waiting. There can be two types of 
feature. A technology feature is an individual operation that the platform 
performs. A policy feature on the other hand, is a constraint on the set of 



WO 98/07282 



8 



PCT/GB97/02157 



operations that a user or provider is willing to perform in initiating or modifying a 
call. Embedments of the present invention relate to this second type of feature. 



Service 

5 



A service is a collection of features. A feature modifies one or more 
aspects of a service, while using the remaining functionality provided. An example 
of a service is that currently offered by the present applicant in the UK: "Network 
Services". This comprises the features "Call Waiting". "Call Diversion". "3 Way 
10 Calling" and others. 



Feature Interaction 



1 5 A feature interaction occurs when the behaviour of one feature affects the 

behaviour of another feature. 

It should be noted that although the word "call" is used throughout this 
specification, embodiments of the present invention should not be taken to be 
20 limited to voice or speech transmission. The principles of the invention will clearly 
also be relevant to other transmissions, for instance potentially involving data or 

information transmission. 

It is recognised that computing infrastructures in telecommunications can 
become extremely complex and this could potentially limit manageability 

25 extendibility, scalability and robustness. The approach exploited in embodiments 
of the present invention, which provides simplicity in the infrastructure, is that of 
intelligent agent technology, the basis of which is described in "Distributed 
Artificial Intelligence", ed. Huhns M. N., Pitman, London 1987. An inteHigent 
agent in this context can be broadly described as a software based entity which 

30 acts on behalf of another entity. It might comprise updatable data, which might 
only be locally relevant, and usually some sort of negotiating or decision-making 
functionality. A community of agents can then perform negotiation tasks amongst 
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themselves to decide a way forward on hph=»if of ™> • 

y lurwara on behalf of multiple entities in a distributed 

system. 

Software clearly provides the basis of the infrastructures needed in service 
provision systems according to embodiments of the present invention to implement 
5 scalab.e and dep.oyab.e solutions. Different types of software technology might 
be employed, and there are severe, functional design approaches which could be 
used. However, a common approach to the design and implementation of 
software systems in this technica. environment uses object oriented software 
technology. This is known and used by international standards bodies ,e.g Open 
10 Software Foundation Object Management Group (OSF OMGI. Open Systems 
Interconnection (OS,,,. Reference might be made for example to "Object 
Management Architecture Guide". Revision 2.0. Second Edition, September 1. 
1992. OMG reference: OMG TC Document 92.1 1.1. 

In genera, terms, "objects" in this context comprise units of software 
15 wh.ch represent entities or concepts of the real wor.d by means of a combination 
of data and functionality. Data is encapsulated as internal attributes of an object 
and the associated functionality is encapsulated as methods which use or operate 
upon the attributes. Although an object may receive a message from another 
object requesting it to perform a method on its attributes which may result in the 
20 return of data, the attributes themselves are not direct.y accessible by externa. 
ob,ects. Such high degrees of enca P su.ation have not been readily avai.ab.e in 
earlier software technologies. 

Embodiments of the present invention are advantageously based on 
object-oriented technology. 

25 From the perspective of the enterprises involved in satisfying the overall 

recrements of users in the future, there are like«y to be significant challenges 
■nvo.ved in designing a suitable infrastructure. A potential starting point wou.d 
clearly be provision of an architecture [from high-level design to .ow-leve. 
■mplementation, that can technically and economically support services of the 

30 future. Software and hardware resources of the computing infra-structure wou.d 
be enabling components of the service architecture. An aspect of the computing 
mfrastructure is the processing environment and a known environment of suitable 
type for use in embodiments of the present invention is the distributed processing 



WO 98/07282 



10 



PCT/GB97/02157 



env, r „„me„, ,DP E1 which aHowsmultipie ^cesses to b> ,„„ ysing 
com p u,e, "nodes". The OPE maintains a view o, the mu„i pl e nodes and processes 
and hand.es message passing between nodes end objects, providing a common 
language ,o, ,he exporting o, interfaces for different objects residing on different 
» nodes. That is. „ assists with aspects o, the software and hardware location 
transparent and faefctes the provision „, S ca,ab,e and deployabie solutions 
Standards for DPE already exist and are being extended. 

A node in this context might convenient* be provided by a computer with 
processors and memory which is capabie „, running ,„ „ peratin9 system 
10 compatib,. distributed P rocessi„ g p ,a„„ rm a „d objects executed as processes on 
the computer. 

Another advantageous characteristic wou.d be that the communication 
network ,or networks, itself is capable of transmitting, a wide range of services 
There are network techno.ogies which are capab.e of supporting muhiple service 
1 5 de.ivery and some examples of these are based on the asynchronous transfer mode 
(ATM) and synchronous digital hierarchy ( SDH) techno.ogies. A common feature 
of such networks is that they can use a range of transmission rates f.exibfy 
choos.ng that most appropriate for the service being delivered. 

Future service retailing might be offered across an architecture of the 
20 te.ecommunication information networking architecture type. This brings together 
elements of the mu.ti-service network and DPE techno.ogies mentioned An 
examp.e of such an architecture is that being defined by the TINA Consortium 
Reference might be made to "Telecommunications .nformation Networking 
Architecture", Oshisanwo A.. Boyd T., Proc. 4th IEEE Conf. Telecommunications 
25 IEEE, London 1993. 

Embodiments of the present invention will now be described, by way of 
example only, with reference to the accompanying Figures in which: 

Figure 1 S b 0ws jnformation( computatjona| an(J engjneerjng 

representations of a system architecture for use in designing embodiments of the 
30 present invention; 

Figure 2 shows the structure of a DPE relevant to Figure 1; 
Figure 3 shows a principally hardware view of platform for use jn 
embodiments of the present invention; 



i 

t 
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Figure 4 shows an overall multiple agent architecture and communication 
links between agents and supporting elements; 

Figure 5 shows an internal architecture for a user agent for use in the 

architecture of Figure 4; 

5 Figure 6 shows a data set relevant to a user agent as shown in Figure 5- 

F.gures 7 and 8 show protocols for user agents of a caller and a cal.ee 

during call set-up; 

Figure 9 shows a high level system model for embodiments of the present 

invention; 

10 Figure 10 shows an object mode, for the appiication described as an 

embodiment of the present invention; 

Figures 11 and 12 show process steps involved in logging on and 
attempts to make a call using an embodiment of the present invention; and 

Figure 13 shows a goal hierarchy for use in solutions according to the prior 

15 art. 

TECHNICAl r?f?NTFXT 

As mentioned above, a suitable technical context for embodiments of the 
20 present invention would be an information networking architecture of the type 
defined by the Telecommunications Information Networking Architecture 
Consortium (TINA-C). Such an architecture is based on Open Distributed 
Processing ,ODP, principles of ob je ct orientation and distribution, applied to 
telecommunications system design using Telecommunications Management 
25 Network (TMN, managed objects and .nte.ligent Network (IN) concepts for service 
management and control. 

In a TINA-C architecture, there are three sets of concepts, a .ogica. 
framework architecture, a service architecture, and a management architecture. 

The logical framework architecture defines concepts and principles for the 
30 design of object-oriented software that operates in a distributed environment. 
Here a traditional layered computer architecture is defined, with computers and 
computer networks at the bottom, a distributed processing environment (DPE) in 
the middle, and (object-oriented) application software on top. 
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The application software is itself subject to organisation in TINA-C. The 
service architecture defines basic object types, and rules for their usage that can 
be used to design application software that provides services. A service is defined 
as a meaningful set of capabilities provided to a user. A service may have many 
5 users in different roles. For example, the end-user is the person who uses the 
service for its intended function, the service manager manages the service, and the 
network provider provides and manages the underlying resources required by a 
service. The notion of service in TINA-C applies to all applications that are 
accessible to users, including management services. The service architecture 
10 contains a call model suitable for a wide range of service types. 

The management architecture defines object types, and rules for their 
usage, that can be used to design application software to manage services, 
networks and computing systems. 

The (known) OMG type DPE core provides for communications between 
15 objects, provides dynamic bindings via a trader function and provides notification 
servers to give management information {such as faults, performance and the like). 
It provides generic "Application Programming Interfaces" (APIs) and message 
passing facilities. All application software is assumed to run on a DPE. 

Available documentation, in addition to the reference given above, 
20 includes a set of deliverables, such as "0-0 Modelling and Design", by J 
Rumbaugh et al, published by Prentice Hall in 1991. "Overall Architecture" TINA-C 
Deliverable 1994 by M Chapman et al and "Guidelines for the Definition of 
Managed Objects", published in "The Management of Telecommunications 
Networks" edited by R Smith et al and published by Ellis-Horwood in 1992. 



25 



System Desion Technique 



Referring to Figure 1, to enable system design according to a TINA-C 
architecture, three ODP viewpoints can be selected, these being as follows: 

30 

Information: a viewpoint on a system that focuses on the semantics of information 
and information processing activities in the system. 
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Computation*: a viewpoint on a system that focuses on the distributable software 

objects and their interactions. 

Engineering: a viewpoint on a systern that focuses on the dep(oymem gnd 
distribution aspects of the system and on the infrastructure to support distribution 

5 

For each of these, a set of modelling concepts are defined, providing a 
vocabulary that can be used to specify a system in the viewpoint addressed. 

The information modelling concepts shown in Figure 1a provide the 
framework for information specifications, describing the types 801. 802 of 

10 information used in a system and the activities that are performed on the 
information. An information specification describes the semantics of the problem 
domain that the application software is being designed for. For example, in a 
banking scenario an information model may contain objects such as account, debit, 
credit, and balance, and relationships such as debits plus credits equals balance. 

1 5 The fundamental concepts of information modelling are objects, which are 

information bearing entities, object types 801, 802. that classify objects and 
define an object's characteristics in terms of attributes and operations that may be 
performed on objects, and relationships 803 that define links between, and 
aggregations of, objects. 

20 Within TINA-C the notation chosen for information specifications is the 

ISO/IEC and ITU-T recommended GDMO (Guidelines for the Definition of Managed 
Objects) with CRM (General Relationship Model). GDMO is extensively used in the 
TMN community for information modelling and thus allows TINA-C to directly 
reuse this work. Rumbaugh's OMT (Object Management Tool) notation (described 

25 in "Object-Oriented Modelling and Design", by Rumbaugh et al, published by 
Prentice-Hal. in 1991, is used for graphjcal representatjon Qf informatjon 
specifications. 

The computational modelling concepts shown in Figure lb provide the 
framework for computational specifications. A computational specification 
30 describes distributed telecommunications applications in terms of computational 
objects 805 interacting with each other. Computational objects are defined 
without any knowledge of where the computational objects wi.l eventually be 
deployed i.e. distribution is made transparent. This al.ows for the specification of 
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a software system that can to.erate the redeployment of software onto different 
nodes of a network without affecting the specification. The fundamental concepts 
of computational modelling are objects 805 and interfaces 806, 807. Objects are 
the uni «s of programming, and encapsulation. Objects interact with each other by 
5 the sending and receiving of informal to and from interfaces. An object may 
prov.de many interfaces, either of the same or different types. There are two 
forms of interface that an object may offer or use: operationaI jnterface 806 gnd 
stream interface 807. An operational interface 806 is one that has defined 
operations, that a..ow for functions of an offering (server, object 809 to be invoked 
10 by other (client, objects. An operation may have arguments and may return 
results. A stream interface 807 is one without operations (i.e. there is no notion 
of .nput/output parameters, requests, results, or notifications,. The establishment 
of a stream between stream interfaces 807 allows for the passing of other 
structured information, such as video or voice bit streams. 
15 A notation which might be chosen for computational specifications is 

TINA-C ODL (Object Definition Language,, which is an enhancement of OMG IDL 
(Object Management Group Interface Definition Language,. T.NA-C has extended 
OMG IDL to allow for the definition of objects that have multiple interfaces and for 
the definition of stream interfaces. 

The engineering modelling concepts shown in Figure 1c provide the 
framework for engineering specifications. An engineering specification describes 
the deployment view of a system in terms of which computational objects 805 
809 are placed on what computing node 810. It also defines the infrastructure to 
allow objects to execute and communicate with each other 

25 

DPE an d Hardware Cnntg nT 

Referring to Figure 2, the infrastructure aspects of the engineering model 
w,l. define the Distributed Processing Environment (DPE,. As mentioned above 
30 the DPE is an infrastructure (of known type, that supports the interactions of 
computational objects. The DPE shields applications programs from the 
heterogeneous and distributed nature of the underlying environment, and provides 
the mechanism that allows objects to interact without knowing the computing 
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nodes 810 they are on. The DPE defines four types of entity: DPE kerne , 811 
kernel transport network 901. DPE stubs, and DPE servers 809. 

The DPE kernel defines a core set of communications, storage and 
processing capabilities (e.g., protocol stack). This core set is assumed to be 

5 present on each node. 

The kernel transport network 901 is a communications network to which 
all DPE kerne.s are attached in order to exchange messages to facilitate object 
mteraction. , t i s defined in order to logicaHy separate the computing network from 
a transport network which is used for the transmission of voice and video The 
10 log,ca. separation recognises that the two networks may have differe nt 
requirements on quality of service. However, they may both be implemented by 
the same physical network. 

DPE stubs are software modules linked with computational objects which 
.nterc.pt interactions on objects, and use the underlying kerne, transport network 
15 901 to establish bindings and to transmit and receive invocation messages to and 
from remote objects, .n practice, an interface for an object is designed and 
comp,.ed. This generates a stub which wi.l receive incoming messages to the 
object and se.ect which operation is to be invoked by means of the interface. 

DPE servers 809 provide infrastructure support. Two examples might be „ 
20 trader and a notification server. A trader provides a run-time mechanism that 
allows objects to locate the interfaces of other objects. A notification server 
enables objects to emit notifications (i.e. significant events that occur during the 
l.fet.me of an object, to other objects. Objects wishing to receive notifications 
register at run-time with the notification server. 
25 Referring to Figure 3, the hardware view of a system in which 

embodiments of the present invention might be built is based on a transport 
network 1100 which wi„ carry for instance voice and data services, provided by 
service providers to users. The users wil. be connected to the network by different 
P.eces of customer premises equipment (CPE) 1101. 1102. The various parties 
30 .nvo.ved in offering and carrying those services, such as the service retailer 
serv.ce provider and network provider, are also connected at computation^ nodes 
810 to the transport network 1100. Intelligent software agents, for instance a 
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terminal agent 102 and a user agent 107, will sit on either the same or different 
ones of computational nodes 810 connected to the transport network 1 100. 

As shown in Figure 3, the terminal agent 102 and user agent 107 sit on 
the same computational node 810. These agents are provided with data of various 
5 types, including for instance user profiles in a user profile store 1103 which 
happens to share the computational node 810 with the user agent 107 and 
terminal agent 102. Other data stores available by means of the transport network 
1100, as shown, might for instance include a management information data store 
1105. The management information data store 1105 may provide global 
10 management information in respect of services. Each computational node 810 is 
provided with a DPE kerne! 811, and therefore a protocol stack for use according 
to DPE principles. 



15 



"Session" and -Access" Cnncopfc 

TINA-C systems make use of "session" concepts and "access concepts. 
These are as follows. 

Session concepts define those objects and interfaces that are required to 
support the initiation of, interaction with, and termination of services. Although 

20 services by their nature are different from each other, they all have a common 
fundamental property in that they provide a context for relating activities. Such a 
context is termed a Session. As a generic definition, the term session represents a 
temporal period during which activities are carried out with the purpose of 
achieving a goal. Three types of session have been identified: service session, 

25 user session, and communications session. 

A Service session is the single activation of a service. It relates the users 
of the service together so that they can interact with each other and share entities, 
such as documents or blackboards. A service session logically contains the 
service logic. A service session is computationally represented by a service 

30 session manager. A service session manager offers two types of operational 
interfaces. The first is a generic session control interface. This provides 
operations that allow users to join and leave a service. For certain services it may 
also offer operations to suspend and resume involvement in a service. The second 
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type of interface will provide service specific operations, and will be dictated by 
the capabilities offered by the service logic. 

The ability to suspend and resume involvement in a service is a desirable 
feature for some services. For example, consider a multi-media conference that 
5 occurs over several days. During the night, when the conference is not in use. it 
should be possible to release expensive communications resources. The service 
session can maintain state about the conference, such as the users and resources 
involved. Maintenance of state and the ability to suspend and resume involvement 
would avoid the need for tearing down and recreating the service each day. 
10 A User session mainta.ns state about a user's activities and the resources 

allocated for their involvement in a service session. Examples of state held in a 
user session include the user's accumulated charge, suspension and resumption 
history, and service specific state such as the current page being edited in a 
distributed document editing service, for example. When a user joins a service 
15 session, a user session is created. It is deleted when he leaves. The service 
session maintains links to the user sessions and thus provides a group oriented 



view. 



A Communication session is a service oriented abstraction of connections 
in the transport network. A communication session maintains state about the 

20 connections of a particular service session, such as the communication paths, 
end-points and quality of service characteristic. A communication session is 
required only when stream between computational objects are required. 
Computationally a communication session manager provides the features of a 
communication session. It provides a connection graph interface of a service 

25 session to manipulate. A connection graph is an abstraction that defines concepts 
such as end-points and lines. A service session expresses connectivity 
requirements be adding, removing and linking end-points and lines. A service 
session manager will request connectivity between stream interfaces of 
computational objects. The communication session manager calls upon connection 
30 management objects to establish physical connections between the network 
access points of the relevant computing node, and nodal services that allow for a 
network access point to be connected to the software stream interface. 
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Connection management components are not discussed further in this 

specification. 

A user can be simultaneously involved in multiple service sessions A 
service session has one or more users associated with it, and for each associated 
5 user there will be a related user session. A service session may have one or more 
communication sessions if the service involves stream communication A 
commun.cation session is related to exactly one service session. 

The purpose of these separations is to decouple service oriented activities 
from connection oriented activities. Many types of services may exist in a future 
10 network and not all wi.l require the explicit establishment of connections (streams) 
The service session is therefore a point of control for all service types, creating 
communication sessions when necessary. 

Access concepts define those objects and interfaces that support user and 
terminal access to services. 

15 Users need to have flexible access to services, in terms of the locations 

from which they access the service and the types of terminal they use User 
access is therefore distinguished from terminal access. An agent concept is used 
m defining the TINA-C access model. An agent is this context is a computational 
object, or collection of objects, that acts on behalf of another entity. 

20 A user agent 107 represents and acts on behalf of a user. It receives 

requests from users to establish service sessions, or to join existing service 
sess.ons. and creates or negotiates with existing service sessions as appropriate. 
The creation of a service session by a user agent 107 can be subject to 
subscription and authentication checks. A user agent 107 also receives and 

25 processes requests to join a service session from service sessions themselves. 
Th,s is a form of in-coming call processing where another user has created a 
service session and invites the user to join in. User agents 107 know the 
subscribed services that a user may create. This list can be presented to the user 
when the user logs on to his user agent 107. 

30 A terminal agent 102 is responsible for representing a terminal. It is 

responsible for obtaining the precise location of a terminal. Two examples are; the 
network access point a portable computer is attached to. and the cell in which a 
mobile phone is currently located. 
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In order to access a service, users must associate their user agents 107 
with terminal agents 102. This is part of a logging on process. A user may be 
simultaneously associated with many terminals. For example, in a video 
conference a user may be using both a workstation and a telephone. Similarly a 
5 terminal may be simultaneously associated with many users, for example, when in 
a meeting all users associated their user agents with the telephone in the meeting 



room. 



User and terminal agents 107, 102 are computational objects that should 
have high reliability properties. These are required so that the network software 
10 can rely on a fixed point for locating users and terminals in an environment where 
both may be moving around. 

1- AGENT ARrHITPHW 

1 5 This section describes the architecture of agents involved in embodiments 

of the present invention. It is important to note that the application described in 
the following example(s) only builds intelligence into the user agents, i.e. the 
negotiation process only occurs between the user agents. Thus, while Terminal 
Agents and Network Agents exist, there is no intelligence in these agents for the 

20 purpose of the present description. 

11 Inter-Agent Archit»cti ir<f 

Referring to Figure 4, agents 405 are located on a number of hosts 810. 

25 Each host 810 has a UNIX process running, called an "office" 400. 
Communication between hosts 810 is carried out through the "office" process 
400. The communication is based on TCP/IP sockets, using a port (eg port 7000). 
Communication between agents 405 and an office 400 located on the same host 
810 are performed through "pipes". Information from the Terminal Agents is also 

30 communicated to User Interfaces 410 through the same communication 
mechanism. 

1-2 Intra-Aqent Architp^trff 
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Referring to Figure 5, the intelligence of the User Agent 107 is comprised 
of five principal objects: Customer 500. TermSession 505. Session 510 
Negotiator 515 and Evaluator 520. Two other objects, io and parser 525,530 are 
5 required for communication from other objects and agents, and ensuring messages 
are passed on to the appropriate object. The following sections give an overview of 
the functionality of each object. 



10 



Customer Object 500 

The customer object handles:- 



(i) logging on and off 

(ii) initial queries concerning the configuration information 
15 (iii) initial request to accept a call from a caller 



TermSession Object 505 



A terminal session object is created by the caller whenever a request is made to 
20 logon at a terminal. The TermSession object 505 handles the initial request by the 
Caller to make a call 



Session Object 510 

25 A Session object 510 is created whenever a new call is made. The following 
functionality is provided:- 

(i) Receiving messages concerning the termination of calls either by the callee or 
from the network 

30 (ii) Sending requests for user validation to the User Agent Manager 
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Negotiator Object 515 



5 A negotiator object 515 is created upon creation of a session object 510 and 
succesfu. validation of a User Agent 107 by the User Agent Manager. The 
negotiator object 515 hand.es which message operations to send between the 
caller and callee's User Agent 107 when a call attempt is made. 



10 Evaluator Object 520 



The Evaluator object 520 calculates the initial proposa! and subsequent responses 
to a proposal when a call attempt is made 

15 

2 - KN QWLEDGF REPRFSPWT/^T ^pj 

Referring to Figures 3 and 6, the user agent 107 contains all the current 
intelligence. It accesses stored information in the User Profile and User Policies 
20 datastore 1103. The User Profile contains information on a user's id, password 
and their preferences while the User Policies datastore holds information on the 
strategies which should be deployed. 

The preferences may include information concerning when calls can be set 
up at later times (i.e. dynamic time-of-day routing). 
25 When a user logs on, they access the user agent 107 via the User Agent 

Manager ["CustMan Object" in the Termina. Agent). The user agent 107 accesses 
the user profile 600 for that user and displays it on screen. 

If a user logs off from a terminal, the mode will be changed either 
automatically or by the user. Otherwise, a user may simply change modes to 
30 mdicate they have temporarily left a machine without logging off. 
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2.1 Feature Representation 

Referring to Figure 13, in known agent-based systems such as that 
described by Griff eths & Velthuijsen (referenced above), a goal hierarchy 1300 can 
5 be used to represent the possible plans which can achieve the goals of all the 
agents involved. 

In Figure 13, one subscriber who has an unlisted number proposes a call to 
another subscriber with calling number delivery (CND). As the subscriber with an 
unlisted number does not want his or her number to be generally known, this 

10 unlisted number (UN) feature is incompatible with the calling number delivery 
feature. On receipt of this proposal, CND sees that the proposal does not include 
the delivery of the number and thus returns the previous proposal with calling- 
number-delivery added. UN receives this proposal and decides that it is 
unacceptable. However, he is able to offer a counter-proposal, using his goal 

15 hierarchy, with the name delivery instead of the number delivery. This is 
acceptable to CND and thus returns notification of this agreement. 

While, this represents a useful approach in terms of considering the user's 
behaviours, there are a number of limitations: 

20 (i) the representation is not rich enough to model more complex constraints such 
as time; 

(ii) there are no preferences expressed as to which of the possibilities a user would 
prefer; 

25 

(iii) a single goal hierarchy is required for all users. Some users may not wish other 
users to know their user policies; and 

(iv) the model could not represent combinations of achieving a call via other 
30 mediums of transmission. 

In embodiments of the present invention, at least one or more of these 
limitations can be overcome. A feature can be represented in terms of a high level 
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goal. Taking the goal of not wanting to be disturbed unless urgent, this can be 
expressed in the form of an ordered set of lower level, alternative goals: 

i) wanting all calls to go to a mailbox 
5 ii) to be delegated to some named person, 
iii) or, if urgent, will take the call 

High level goals can thus be mapped into sets of alternative call 
configurations which can be ranked according to preference. This mapping can be 
10 hard coded or achieved through a set of ru | es which will dynamically assign 
preference ratings based on a series of questions which guide the user as to which 
goals they wish to achieve. 

As an example. Call Waiting is a service which can be represented as the 
more general goal of a user not wanting to miss urgent calls. 

These high level goals can be used to describe both incoming and outgoing 
calls. Some further examples are given in the table below:- 



15 



High Level Goal 



Outgoing Calls 



I don't want callees to know my phone number 



' want outgoing calls to complete now rather than later 



' want to reach the person concerned if possible rather than voicemail 



' Wam t0 reserve a time to call back if pos sible if the callee's line is busy (this 
might be an urgent call or because I am only available now) 



I want ca„ee to reserve a time to call me back if poss.ble ,t their line is busy 
Incoming Calls ' " ■ ■ 



I do not want to be disturbed unless it is urgent 



I do not want to take calls between times x and y 
I want to know who's calling me before I answer 



want all incoming calls to complete 
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2.2 User Confirm,-^,, 

A user's configuration describes how a user prefers their calls {incoming 
5 and outgoing) to be handled. The user's configuration defines, for both incoming 
and outgoing calls, a set of call configuration options. Each call configuration 
option within the set is represented by a set of attributes, together with their 
associated values, and a basic preference rating. Some of the attributes will be 
fixed, while others will specify a range of values. In the latter case, a numerical 
10 indicator will be specified with one or more of the alternative values which 
indicates an amount to be decremented from the basic preference rating. Thus, 
each call configuration option of the set has a range of associated preference 
ratings. This is further discussed below. 

By defining a preference structure in relation to a set of call configurations, 
15 the user can give priority to one choice of call configuration over another and thus 
determine a negotiation pattern for that user's agent. 

It might be noted that the user agent 107 is persistent. Decisions can 
therefore be made whether or not the user is active. Also, preferences will usually 
be set, or changed, prior to call set-up, rather than during. 

The following describes firstly the attributes for use in call configurations, 
and then how a preference structure is applied to those attributes, for a particular 
user. 



20 



25 



2.2.1 Call Configuration Attributes 

The attributes describing a particular call configuration are communicated between 
agents during a negotiation process in the form of proposals and counter- 
proposals. A call configuration is defined by the following attributes:- 

30 (i) caller values: {person, recorded} 

This attribute defines who is calling. The caller may be an actual person or it may 
be a recorded message in the case when the callee is not available to receive calls 
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or mail messages at the present time. The caller may leave a recorded message 
which then gets sent to the callee at a predetermined time or when the callee next 
logs on. 

5 (ii) callee: values: {person, queue, mailbox} 

This attribute defines how the callee wishes to handle a call. There are three 
possible values: either (i) the call will be taken by a person directly, (ii) the call can 
be put in a queue, or (iii) the call can be sent to the mailbox. 

10 

(iii) callee-who values: {direct, someone-else [X,Y,„]} 

This attribute defines whether the callee will be the person requested or whether 
the call will be taken by someone else. In this latter case, a parameter specifies a 
1 5 list of delegates. 

(iv) authorised values: {yes, no} 

This attribute defines whether the call needs an authorisation code. 

20 

(v) medium values: {voice, video, text} 

This attribute defines which medium is being used to transmit the call. The 'video' 
value includes voice. 

25 

(vi) schedule values: {now, caller [time], callee [time]} 

This attribute defines whether the call is to be taken now or whether it will be 
taken later. In the latter case, it defines the responsibility for setting up the call 
30 (caller/callee) and a time parameter which specifies one of the following 
possibilities: 'before tr, 'after tr, 'attT, 'asap'. 



(vii) caller info values: {none, name, number} 
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This attribute represents what information the caller is prepared to provide to the 
callee. It may take a subset of the above values. 

5 {viii) callee info values: {none, name, number} 

This attribute represents what information the callee is prepared to accept from the 
caller. It may take a subset of the above values. 

10 2.2.2 Call Configuration Options Ordered by Preference Ranges 

It is possible to identify a "mode" of operation for a user. This is in 
practice a high level goal which predetermines some lower level goals and defines 
a context of operation such as calls to be directed to a mailbox, or person to 
15 person only. In practice, the mode can be selected, or determined, by selecting 
values from the first two or three attributes in a call configuration: caller, callee 
and callee-who. {The third attribute is only required if the second attribute uses 
the value 'person'.) 

20 "Do Not Disturb" Mode 

In an example, shown in Figure 6, a user's top priority might be for all 
incoming calls to be diverted to the mailbox. If this cannot be achieved, calls 
should be delegated to a named person, and failing that the call might be taken if it 

25 really is urgent. This high level goal, with the three options, could be expressed in 
the form of a 'do not disturb' mode 600. Each option for the "do not disturb" 
mode is given a basic preference rating, selected to reflect the order of preference. 
Hence the basic preference rating for "Mailbox" option 605 might be 100, for the 
"delegated" option 610 the basic preference rating might be 90, and for the "call 

30 taken" option the basic preference rating might be 79. 

Looking at the "Mailbox" option 605, the top priority can be expressed by 
selecting the following values for the first three attributes and assigning the 
maximum basic preference rating to this choice: 1 00. 
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Preference Value: 


100 


Caller 


person 


Callee 


mailbox 


Callee-who 


direct (default value) 



Having defined these attributes, values can then be defined for the other 
attributes. For each of these attribute values, there may also be user preferences. 
5 For example, the user may prefer calls to be authorised and/or the medium to be 
voice rather than video. These preferences can be expressed by decrementing the 
basic preference rating for the "Mailbox" option by a relevant amount for each of 
the alternatives it is preferred should not be accepted. That is, each such 
alternative value is given a negative preference rating. A minimum preference 
10 rating for a set of call configurations providing one of the three options (ie the 
bottom end of the preference range for that option) can therefore be determined by 
summing all the possible negative preference ratings which can occur within a 
single call configuration and subtracting this from the basic preference rating for 
the option. 



15 



One possible set of values are shown below for the mailbox' option 605: 



Preference Range 


100- 92 


Caller 


person: yes<0), recorded: no 


Callee 


person: no; queue: no; mailbox: yes (0) 


Callee- Who 


direct: yes (0) 


Authorisation 


present: no | absent: yes (0) 


Medium 


voice: yes(-3) | video: yes (-5) | text : yes(O) 


Schedule 


now: yesfOI | caller calls back: no | callee calls back: 
no 


Caller Info 


Forename: present: yes(O); absent: no 
Surname: present: yes(O); absent: no 
Company: present: no; absent: yes (0) 


Callee info 


Forename: present: yes(O); absent: no 
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Surname: present: yes{-3); absent: yes (0), 
Company: present: no; absent: yes (0) 



The table above defines a set of proposed call configurations for the "Mailbox" 
option 605 (ie where the callee is "mailbox"). The basic preference rating has 
been set at 100 because the user prefers this option most. There are three values 
5 with negative preference ratings, these being where the medium is "voice" or 
"video" and the callee surname is present. The worst combination available 
available is medium being "video" (-5) and callee surname present (-3). This 
provides a sum of -8. Hence the preference range for this "Mailbox" option 605 is 
100-92. 

10 

An example of one proposed call configuration within this option may be 
defined as: 



caller: person 
15 callee: mailbox 

calleeWho: direct 

authorised: absent 

schedule: now 

medium: text 
20 caller forename: present 

callee forename: present, surname: present 



which produces a preference rating for this particular user of 97, based on the 
basic preference rating (100) minus the preference rating for the callee surname 
25 present I -3). 

This process is repeated by defining the set of call configurations, together 
with preference ratings, for the two other options for the mode "Do Not Disturb": 
delegated calls 610 and receiving a call 615. The 'do not disturb' mode is then 
defined by the union of these three sets. 
30 As shown in Figure 6, another available mode might be "No Calls" 620. 

This only differs at first sight, as shown, in the last option which replaces "Now - 
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Take Call" with "Later" 625. However, the preference ratings for the first and 
second options in this mode, "Now - Mailbox" 630 and "Now - Delegate" 635. 
may actually be very different in this mode from what they are for the same 
options in the "Do Not Disturb" mode 600. Indeed, as shown, the preference 
5 ranges are now 1 00 - 87 and 85 - 70 as shown. 

An analogous outgoing mode, 'completing a call', may represent the goals 
in decreasing preference of attempting to call a person directly, accepting a 
delegated call, or failing that leaving a message. 

The total set of call configurations for incoming and outgoing calls define a 
10 user's "negotiation space", which provides the framework to enable the user 
agents to make decisions about which goals they wish to achieve. 

2.2.3 Example 
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In the following example, the caller, Mr Smithers wishes to call Mrs 
Richers. Mr Smithers prefers to call Mrs Richers directly rather than leave a 
message in her mailbox. He also prefers to setup the call now rather than set up 
the call later. 

Mrs Richers on the other hand, is in the 'do not disturb' mode. She does 
20 not want to be interrupted now. 

This information can be represented by the two sets of call configurations 
shown below. A negative number alongside an attribute value indicates that 
should that option be taken, the preference rating will be decreased by that 

amount. 

25 Where no multiple values are specified, this implies that only that value 

will be acceptable in that particular set. 

2.2.3.1 Caller's ordered set of Call Configuration Options {i.e. Mr Smithers'): 
30 Mode: Contact person now either person-to-person or leave mail message. 



Call Configuration Option a): Preference Range: 100-91 
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30 

Caller: person 
Callee: person 
who: direct 

authorisation: no/yes (-1) 
5 medium: voice 

schedule: now/caller sets up call later (-8) 
caller info: none 

Call Configuration Option b): Preference Range: 90-80 

10 

Caller: person 
Callee: mailbox 
who: direct 

authorisation: no/yes (-1) 
15 medium: voice/text (-9) 
schedule: now 
caller info: none 

2.2.3.2 Callee's ordered set of Call Configuration Options (i.e. Mrs Richers'h 

20 

Mode: Do not disturb 

Call Configuration Option a): Preference Range: 100-90 

25 Caller: person/recorded (-1) 

Callee: mailbox 

Who: direct 

Authorisation: no 

Medium: voice/video/text (-3| 
30 Schedule: now 

Callee info: name/[ J (-6) 

Call Configuration Option b): Preference Range: 90-80 



! 
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Caller: person/recorded (-1) 
Callee: person 

5 Who: someone-else (Fred] (-5),/someone-else fGeorgeJ {-7|, 
Authorisation: no 
Medium: voice/video 
Schedule: now 
Callee info: name/none (-2) 

10 

Call Configuration Option c): Preference Range: 80-70 



Caller: person 
Callee: person 
1 5 Who: direct 

Authorisation: yes/no (-6) 
Medium: voice/video 
Schedule: caller set up call later 
Callee info: name/none (-4) 

20 

2.2.4 User Profile 



A user's profile describes the mapping from the set of high level goals 
defined by the user to the call configurations. An example is given by Figure 6. 

25 

3. NEGOTIATION 



On making a call, a user triggers their user agent. The user agent refers to 
the user's profile, generates a proposal and transmits it to the callee's user agent. 
30 The proposal will comprise one or more call configurations. 

On receipt of a proposal, a negotiation process is initiated. The callee's 
agent is required to accept the proposal, counter with a proposal of their own or 
reject the proposal. To do that, the callee's user agent will first review the 
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proposal against their own modes, options and preferences to see if there is at 
least one acceptable call configuration in the proposal. If there isn't, the callee's 
user agent needs to generate a counter proposal, unless the incoming proposal 
was too far below the callee's agent's stored preferences. If the latter is true, then 
5 the callee's user agent may reject the incoming proposal and the connection will 
simply fail. If it isn't true, the callee's agent may send back a counter-proposal 
and the negotiation will continue. 

Each agent involved determines their response to a proposal or counter 
proposal in the negotiation process by taking into account their set of preferences 
10 within a given context. The aim is to select and put in place a call configuration 
which describes a mutually acceptable call handling scenario. That is, a call 
configuration which falls in the negotiation space of both agents. 

Referring to Figures 7 and 8, the negotiation process is now described in 
more detail. 

15 A proposal, or counter-proposal defines a particular call configuration. In 

order to communicate these proposals and counter-proposals between user's 
agents, a number of performatives are introduced. These performatives are given 
below together with an informal description:- 

20 



25 



30 
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Performative 


Description ~~ — ^— — 


accept-if 


Th.s offer describes a set of proposals which are acceptable. It 
does not however exclude other possibilities which are not 
specified in this offer. 


fail-if-not 


This offer describes a set of proposals which if the other user 
does not accept, forces a failure and the end of the negotiation 
process. 


acceptance 


the caller/callee user's agent have agreed to a proposal or counter" 
proposal 


resolution 


the callee has agreed to the proposal put forward by the caller 


failure 


me caiier/callee's User Agent or the caller/callee cannot agree to 
any proposals and so the negotiation ends 


succeed 


the caller and callee's User Agent have already agreed to a set of 
proposals and now the caller/callee chooses which particular 
proposal from the set of proposals offered. It is possible that a 
caller will send a set of proposals which is a singleton. In this 
case, the callee can subsequently receive a resolution. 



3.1 Protocol 



Referring to Figures 7 and 8. the protocol is defined using a state 
transition diagram to show the sequence of permitted messages for both the caller 
and callee. For the purpose of these diagrams, an exclamation mark (!) indicates 
'send' to other user and a question mark{?) indicates 'receive' from other user. 

A further constraint is also placed on the protocol such that if a 
configuration has been proposed using an 'accept-if performative, and it has been 
refused by the other parties involved in the negotiation, it is not possible to repeat 
this configuration. 

Negotiation is based on: 

• the knowledge representation used to express the goals and preferences 
between goals 

• the strategy used to determine the type of proposal to send and how to 
evaluate a proposal received from another user's agent. 
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The knowledge representation has been discussed above. It is the use of 
goals, expressed as call configuration attributes, together with the associated 
preference ratings. Interagent communication is then carried out. using knowledge 
5 representations, according to a protocol of the following type. 

Figures 7 and 8 show state transition diagrams for a caller and a callee 
respectively. They describe what message operations are possible given the state 
(initial/proposed/confirmed/succeed) 705, 710, 715, 725 and which party 
(caller/callee) has sent the message. A number of possible events (proposal, 
10 counter, succeed (proposals), acceptance, resolution and failure) 720 can occur at 
each given state. 

The object structure describes the content of the negotiation, which in the 
context of this application, is the proposal describing the combination of call 
characteristics to be performed. 

15 

3.2 Decision Process 



This section describes:- 



• how an individual agent makes a decision as to which message operation to 
send, and 

• how an agent decides upon the content of the proposal or counter proposal if 
one is offered. 



25 3.2.1 Environmental parameters 



When a request is made by a caller to make a call, some static information is used: 
caller (Name) - the name of the caller 

delegated (Via) - if calls have been delegated to someone else, the 'Via' field is 
filled in with the name of the callee who decided to delegate their calls. 

callclass(Class) - the class defines whether the call is business or personal. 
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In addition, proposais must also take account of a number of attributes which 

define the environment:- 



5 (i) mode - determines the context in which the user wishes to make or receive 
calls, e.g. 'do not disturb', 'contact callee directly', etc. 

(ii) state of a session - free, busy 

TO m .ocation - determined by the Termina. Agent which can identify the user's host 
machine which the user is logged into 

(iv) intentions - commitments a user has made together with their associated 
priority 

15 

(v) current negotiations - other negotiations the user is involved in. but which have 
not yet come to a successful conclusion 

These attributes determine the set of proposa.s from which the initial proposal will 

20 be chosen. 

3.2.2. Generating initial proposal 

As mentioned in the previous section, the environmental parameters constrain the 
25 set of possible proposals from which any proposal can be se.ected. The initial 
propose, will be generated by selecting the proposa. from this set with the highest 

preference rating. 

3.2.3 Generating counter offers 

The process given be.ow provides an overview of how a user agent shou.d respond 
to an offer:- 



30 
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1. Find a possible proposal using the next highest preference from profile. This 
preference will take into account the current state of the user, i.e. free or busy, 
together with previous proposals which have failed. If a preference can be found, 
go to step 2. else, send a message back to the other user agent indicating a failure 

5 together with the reason. 

2. Check the possible proposal against intentions. 

If this passes, go to step 3, else go back to step 1 with a message indicating a 
failure together with the reason. 



10 

3. Check the possible proposal against current negotiations. 

If this passes, then send proposal back to other user agent indicating the counter 
proposal together with the reason why counter proposal is being sent. If this fails, 
then go back to step 1 with a message indicating a failure together with the 
1 5 reason. 

Two types of counter offers can be made: 
'Accept if 

20 

This offer describes a set of proposals which are acceptable and have not 
previously been sent. It does not however exclude other possibilities which are 
not specified in this offer. 

25 'Fail if not' 

This offer describes a set of proposals which if the other does not accept, forces 
the end of the negotiation process. This offer reduces the negotiation space. 

30 3.2.4 Strategies 



General 
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A number of strategies can be generated using the form of the counter 
proposals discussed above. One such strategy is shown below.- 



5 1. If 

receive Accept If (proposed) and 
flproposal, myPreferences) = accept then 
send 'accept(proposal)' 

10 The function "ffproposal. myPreferences)" determines whether the proposal is 
acceptable or not by examining the list of proposals. 



the size of the list of possible proposals >size P ro P iist 



1 5 then 



if 

the pref(proposal) > prefaccept (your threshold value) 

then 

accept (proposal) 

20 else 

counter with your best proposal from current negotiation space 



else 



25 2. If 



accept(proposal) 



receive a proposal which is unacceptable (i.e. there is no intersection 
between what has been proposed and the set of acceptable proposals based on 
your preferences), then 



30 

else 



send Tail If Not(whole set of proposals)' 
send 'Accept If (top x% of your preferences) 
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The first step in the strategy will tend to make call configurations lower 
down the preference order more acceptable as the negotiation process continues. 

The parameters sizepropi.st, prefac cep i. x can all be varied giving different 
degrees of co-operativeness. 
5 A mathematical expression defining a strategy is as follows. The strategy 

defines the reasoning used to evaluate the following:- 

• initial proposal to offer 

• counter-proposal from the other user's agent 

10 • response to be made to the other user's counter-proposal 

Let the negotiation space for userj at time t x be defined by NS , tX( where NS; tx is 
an ordered set of call configurations {c^ c 2 , ...,c n } such that Uic,) < U{c| i+1 ), 
where U(C;) represents the preference of c,. Let C ltmtx and C Mx represent the set of 
15 proposals and counter-proposals being offered by user^ and user jf at time t x , 
respectively. We define a number of parameters, which affect a user's degree of 
cooperation 



20 <i) Let G be such that C Klx = {c min c max } f such that c x < c x + 1 , x = min,..,max- 

1, where U[c min ] = G%*U(c ma J. We can think of G as representing the 
generosity of the user and dictates the lowest preference value to offer in a set 
of proposals 

25 (ii) Let D be such that if a set of call configurations, O u tx .,, are offered in a 
counter-proposal, it will be accepted at time t x if length INSj, tx ) < D, and NS it tx . 
i ^ C jt tx _i * 0. The value D represents a user's desperateness to agree to a 
proposal. 

30 (iii) Let A be a constant, such that the set of call configurations, C s tx , will be 
offered at time t x such that: 



UlmintCj, > A%*U[c max ] and C it lx c C, tx0 . 
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where q tx ., was the counter-proposal offered by agent j at time t x .,. This 
parameter defines the level of acceptability of a proposal from the other 



user. 



5 The strategy for user, at stage t„ x > 0, can then be formulated as a set of rules 
defining the proposal. p, lx , offered at time ,t x .. We have three main cases: 

<i) Puo = < accept if. C, I0 > where U[c min J = G%*U[c max ], C, , 0 = { Cfnjn ,.., 

c„,ax ). len(NSj. t0 ) > D. and NS, ,, = NS , ,,\ C, t0 

10 

fii) If Pj . tx ., = < accept-if. C,. >, Vx, x > 0, then we have the following sub- 
cases: 



a> p Mx = < accept-if, C, „ >, U[c min ] = G%*Utc max ), NS , „ = NS , ,„., \ 
1 5 c i. tx-i. if NS j, ,„., o Cj. * 0 and len(NS, ,„) > D, x > 1 

b) p Mx = <fail-if-not. C Mx > and q. Ix = NS, IX = NS, tx ., if 3x > 1, p^., 
* < f ail-if -not, tx0 > and 

20 N S i. t.,-1 r» Cj. = 0, 

a) Pj.« x = <succeed, Ci.,, >, U[c mjn ] = G%«U[c max I, 

« IQ. tx c q. tx ., , U[min(Cj, ,„.,)] > A%«U[ Cmax ], or length (NS,. tx ) s D) 
and NSj, tx-i n Cj, ,„., * 0 

25 

'») <f P i.tx i = < fail-if-not. C u > then we have two sub-cases: 
a ) ,f c j.tx-i «"» NSj,,,,., = 0, then p itx = < failure > 

30 b) If q. tx ., r. NS, * 0 and len(NS, tx ) > D. x > 1 . where NS, tx = (NS , 

n ^ tx-i). then 

p, tx = < accept-if, C, IX >, U[c min J = G%-Ulc max ], C, tx cC, lx . 1 . 
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The parameters G, D and A can be varied to provide a greater or lesser 
degree of cooperation. 

5 There are two important aspects of the strategy set out above, these 

being the "Accept If" and "Fail If Not" mechanisms. Between them, they reduce 
the negotiation space for the user agents in a relatively short number of rounds of 
negotiation, for instance four or five rounds. The "Accept If" proposal reduces the 
negotiation space of the sending agent since those configurations cannot be 

10 resent. The "Fail If Not" proposal limits the negotiation space for both agents to 
what is contained in that proposal. 

The way a negotiation might proceed is that a first agent selects a 
proposal from its top six preferred call configurations. A second agent looks at its 
own negotiation space and finds the proposal doesn't even meet its lowest criteria, 

15 ie the bottom of its preference range. The second agent therefore sends its whole 
negotiation space as a "Fail If Not" proposal. The first agent selects from the "Fail 
If Not" proposal and sends an "Accept If" proposal. For instance, the first agent 
may have found on review that only six call configurations from the "Fail If Not" 
proposal fall in its preference range. The second agent sends back the best one of 

20 the call configurations and the negotiation succeeds and is resolved. 

This type of negotiation strategy clearly has application to negotiation 
procedures other than simply those used in communications, in call setup, and is 
independently inventive in the context of software agents negotiating to select a 
mutually acceptable solution from a negotiation space which comprises a range of 

25 options which can each be broken up into sub-options and weighted preferentially. 
For instance, this would be the case where agents are negotiating to establish a 
pricing strategy over a commodity with multiple components where the 
components can be mixed and matched to get an optimum combination. This 
applies in the travel industry where a product (overseas travel) has many different 

30 components such as travel mode, accommodation and timing. 
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4. CONNECTION SETUP IM TH E TINA-C FIVfVIROMMFMT 

The following describes the setting up of a service session in a TINA-C 
environment, including the use of user agents to implement an embodiment of the 
5 present invention to select and put in place a mutually acceptable configuration for 
the service session. 

The application uses the TINA-C framework as a basis for determining 
individual agent roles and the sequence of interactions between each of the agents 
in order to establish a service session. 

10 (It should be noted that, by adopting the TINA 'session' concept, it is 

possible to avoid the need to represent some features. An example of this is a 
feature called 'Call Waiting', which enables users to switch between two calls. 
This feature does not exist as such in the TINA system, since a user can receive 
any number of calls simultaneously. Every time an incoming call is accepted, a 

15 new 'call' window appears on the terminal screen, which is associated with a 
unique session identifier.) 

Referring to Figure 9, a system model gives a high level view of the 

system. 

The User Agent 107 contains the intelligence to negotiate on behalf of 
20 Users to set up a call. 

The Terminal Agent 102 holds information on the resources available and 
location of a station. 

The Network Agent 110 controls the logical and physical connections 
between the locations of the users involved in calls. 
25 The Application 950 represents the particular program chosen to perform a 

call. This may be for instance a simple voice call or a multi-media conference call. 

The User Interface 410 allows the user to make and receive calls, access 
and change their user configurations. 

30 4.1 Object MoHbI 

Figure 10 shows object models for the principal objects of a user agent 
107 and a terminal agent 102. Descriptions of the objects are given below. 
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4.2 Object Description 

(It should be noted that messages of known type which simply instruct an 
5 object or agent to perform a task are not set out below. Only "speech act 
messages" are detailed. These have a semantic nature, e.g. to inform or request.) 

4.2.1 User Agent 
10 4.2.1.1 Customer Object 1005 
Attributes 

• name - customer's name 
15 • passwd - password 

Creation method 

A customer object is created using the call: 

20 

Create(Cust) 
where the following parameters are used:- 

(i) Cust - Customer 

25 

Speech Act Mesgaqfts 

The customer object respond to the following speech act messages:- 



(I) act = inform, nature = logon, address = Address, password = Password, 
agent = Agent 
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This message emanates from the User Interface via the Terminal Agent informing 
the customer object that the user is logging on. 

(ii) act = inform, nature = logoff, address = Address, agent = Agent 

5 

This message emanates from the User Interface via the Terminal Agent informing 
the customer object that the user is logging off. 

(iii) act = inform, nature = logoff, address = Address, obj = cust. customer = 

10 Customer, password = Password 

This message emanates from the User Interface via the Terminal Agent informing 
about the password 

15 (iv) act = request, nature = config, address = Address, agent = Agent 

This message emanates from the User Interface via the Terminal Agent, 
requesting the User Agent's configuration information 

20 |v) act = inform, nature = config, config = Config, address = Address, agent = 
Agent 

This message emanates from the User Interface via the Terminal Agent informing 
the User Agent of a change in the Configuration information. 



25 



(vi) act = proposal, proposal = Proposal, session = Sessionld, agent = Agent 

This message emanates from the Caller's User Agent via the negotiator object 
requesting the Callee's User Agent to accept an initial proposal 

30 

4.2.1.2 TermSession Object 1000 
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Attributes 

The attributes tor the TermSession object 1000 are:- 

5 • terminal - Terminal Agent 
• location - name of the station 

Creation method 

10 A TermSession object 1000 is created using the call: 

create{Agent, Address) 

where the following parameters are used:- 

15 

(i) Agent - Customer 

fii) Address - location of the Terminal Agent 
Speech Act Messages 

20 

The TermSession object 1000 responds to the following speech act messages:- 

(i) act = request, nature = makecall, callee = Callee, proposal = Password, 
address = Address, agent = Agent 

25 

This message emanates from the User Interface via the Terminal Agent to request 
to make a call. 

4.2.1.3 Session Object 1010 

30 

Attributes 

The attributes for the Session object 1010 are:- 
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• initial proposal - the initial proposal put forward by the caller 

• other agent - the other agent involved in the call setup 

• session id - a unique identifier (Caller User Agent, Id) 

5 

Creation method 

A Session object 1010 is created using the following call: 

10 Create(Agent, Proposal, Session id) 

On creating a session, the following parameters are used:- 

(i) Agent - the other User Agent involved in the call, 
1 5 (ii) Proposal - the initial proposal 
(iii) Sessionld - session identifier 



Speech Act Messages 



20 The Session methods respond to the following speech act messages:- 
(i) act = inform, nature = userquery, response = ok, user = Agent 

A query response from the User Agent Manager to inform the User Agent that the 
25 User Agent (Agent) exists. 



(ii) act = inform, nature = userquery, response = notok, user = Agent 

A query response from the User Agent Manager to inform the User Agent that the 
30 User Agent does not exist. 



(iii) act = inform, nature = connectfail, session = Sessionld 
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A message from the network to inform the User Agent that the connection has 
failed. 

(iv) act = inform, nature = connectend, session = Sessionld 

5 

A message from the network to inform the User Agent that the connection has 
been terminated. 

4.2.1.4 Negotiator Object 1020 

10 

Attributes 

The attributes for the Negotiator object 1020 are:- 

1 5 • state - the current state (initial, proposed, confirm} 

• direct - who is controlling the negotiation (send implies control, receive implies 
someone else has proposed) 

• proposals - a list of proposals seen so far, with the latest proposal at the 
beginning of the list. 

20 • otherneg - the other user agent involved in the session 

• session - the joint negotiation Id generated by the controller 

Creation method 
25 The Negotiator object 1020 is created using the call: 

create! Agent, ProposaiParameter, Sessionld, Direct) 
where the following attributes are used:- 

30 

(i) Agent - the other User Agent involved in the call 

(ii) ProposaiParameter - the proposal made as part of the call 

(iii) Sessionld - the Sessionld created by the caller's User Agent 



f 
I 
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(iv) Direct - who is controlling the negotiation [send implies control, receive implies 
someone else has proposed) 

Speech Act MftSB fl g fl s 

5 

The Negotiator object 1020 responds to the following speech act messages:- 

(l> act = acceptance, session = Sessionld, agent = OtherAgent 

10 This message emanates from the other agent's negotiator object requesting 
acceptance for a call setup. 

(ii) act = counter, session = Sessionld, proposal = OtherProposal, agent = 
OtherAgent 

15 

This message emanates from the other agent's negotiator object informing the 
agent of a counter proposal. 

(iii) act = failure, session = Sessionld, agent = OtherAgent 

20 

This message emanates from the other agent's negotiator object informing the 
agent that the negotiation has terminated unsuccessfully 

(iv) act = resolution, session = Sessionld, agent = OtherAgent 

25 

This message emanates from the other agent's negotiator object informing the 
agent that the negotiation has terminated with a successful conclusion. 

4.2.1.5 Evaluator Object 1015 

30 

Attributes 



There are no attributes for the Evaluator object 1015. 
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Creation methpH 

The Evaluator object 1015 does not have to be created. 

5 

Speech Act Mp^^p^ 

There are no speech acts applicable to this object. 
10 4.2.2 Terminal Agent 

4.2.2.1 iojisten Object 1025 
Attributes 

15 

The attributes of this object are:- 

socket - server socket 
port - socket 
20 loctemplate - address name 

Creation met^oo! 

The iojisten object is created using the call: 

25 

createlport) 
where port refers to a socket 
30 Speech Ar t Messages 

There are no speech act messages. 
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4.2.2.2 io port Object 1030 

Attributes 

The attributes of the io port object are:- 

5 

• socket - socket 

• location - location name 

• customer - customer name 

• program - application (rtgui) 
10 • agent - terminal agent name 

Creation method 

The iojaort object is created using the following call: 

15 

createfsocket, Template} 

where the attributes are:- 

20 (i) socket - socket 

(ii) Template - Template name, containing the host and port number 

Speech Act H /lessaqe ^ 
25 The io_port object responds to the following messages:- 
(i) act = inform, program = Program, host = Host 

A message from the User Interface to inform the Terminal Agent about the 
30 application and host. 

(ii) act = inform, nature = logon, customer = Cust 
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A message from the User Interface to inform the Terminal Agent about logging on. 

(iii) act = inform, nature = logoff, customer = Cust 

A message from the User Interface to inform the Terminal Agent about logging off 

5 

(iv) act = request, nature = config, , customer = Cust 

A message from the User Interface to request the Terminal Agent for the 
configuration information. 

10 

(v) act = inform, nature = config, config = Con, customer = Cust 

A message from the User Interface to inform the Terminal Agent about changes to 
the configuration information. 

15 

(vi) act = inform, nature = makeCall, callee = Callee. mymode = Mode, 
preferences = preferences 



A message from the User Interface to inform the Terminal Agent about a make 
20 call. 



(vii) act = inform, nature = logresponse, address = Cust:Program@Location, 
password = Password 

25 A message from the User Agent via the Customer object to inform the Terminal 
Agent about a response to a logon. 

(viii) act = inform, nature = nosuchcust, address = Cust:Program@location 

30 A message from the User Agent via the Customer object to inform the Terminal 
Agent about a response to a logon and the User Agent does not exist. 



(ix) act = reply, config = Config, address = Cust:Program@Location 
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A message from the User Agent via the Customer object to inform the Terminal 
Agent about its configuration information 

5 4.2.2.3 User Agent Manager (Cust Man) Object 1035 

Attributes 

The attributes for the custman object are:- 

10 

• functor - function of the agent (i.e. user agent) 



1 5 There are no parameters called to the create method: 
Speech Ant Messag es 

The custman object responds to the following speech act messages:- 



20 



25 



(I) act = inform, nature = logon, address = Address, password = Password, 
agent = Agent 

This message emanates from the Terminal Agent requesting a logon, 
lii) act = request, nature = userquery, user = User, agent = Agent 



This message emanates from the User Agent requesting a query of the existence 
of the agent (User). 

30 

5. SCENARIOS 
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Referring to Figures 1 1 and 12, the following process steps apply during log on by 
a user and a call attempt by a user. It will be seen that the numbers given below 
to the process steps are repeated in Figures 1 1 and 1 2 to indicate which entities 
are involved in each process step. 

5 

5.1 User Log ging Qn 
Process 

10 The User opens the runtime application. 

1,2. A 'login window' is displayed once the User Interface has registered a 
connection with the Terminal Agent 



5 3. The User enters his/her userld and password. A message is sent to the 
Terminal Agent to request logging on, together with the userld and password to 
the Terminal Agent. 



4. On receipt of this request, the Terminal Agent passes on the request to the 
20 User Agent Manager. 

5. The User Agent Manager sends this message on to the relevant User Agent via 
its customer object. 

25 6. The Customer object creates a Termsession object, identified by the Terminal 
Agent which sent the message and the name of the station being used. 

7. The Caller's User Agent via the customer object determines the validity of the 
user. If the password is correct, a message is sent to the Terminal Agent. 

30 

8. On receipt of a 'logresponse' message, the Terminal Agent sends a message 
back to the originating User Interface located on the identified station. 
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At this point, the main application window is displayed, enabling users to make or 

receive calls. 

5.2 User Attempting Tn M fike A C ^ff 

5 

Process 

1. On selecting the 'make call' button from the User Interface, a message is sent 
to the Terminal Agent, containing the proposal, calleelD, mode, preferences and 

10 customer. 

2. On receipt of the message, the caller's Terminal Agent sends a message 
containing the calleelD, current location, situation and proposal to the caller's User 
Agent via the TerminalSession object. (The preferences are not used at this point. 

15 This only defines who is being called and the mode which has been selected - it is 
not until Step 7 that the preferences based on the mode and other factors such as 
current state, are used to generate a proposal). 

3. On receipt of this message, the Terminal Session object creates a new Session 
20 object. 

4. If the Sessionld is empty, then a new Session identifier is created using the 
ordered pair, (Caller's User Agent, Id). The Caller's User Agent will then send a 
message to the User Agent Manager to query the validity of the Callee. 



25 



If the Sessionld already exists, then the user is responding to a request to join in 
an existing session. (see Step ) and the Sessionld will be taken from the existing 



session. 



30 5. On receipt of this message, the User Agent Manager validates the Callee and 
sends a message back to the Caller's User Agent via the Session object with the 
appropriate response. 
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6. On receipt of a successful response, the Session object creates a negotiator 
object, identified by the Sessionld. 

7. On creation of the negotiator object, the negotiator requests the evaluator to 
5 generate an initial proposal. 

8. The negotiator object sends the proposal together with the Sessionld to the 
Callee's User Agent via the customer object. 

10 9. On receipt of this message, the Callee's User Agent via the Customer object 
creates a Session object using the existing Sessionld. 

10. The Session object creates a Negotiator object for the Callee's User Agent 
using the existing Sessionld. 

15 

1 1. The negotiator object asks the evaluator object to calculate a response to the 
initial proposal. 

1 2. A message is sent back to the Caller's User Agent via the Negotiator object 
20 with the appropriate response. 

1 3. On receipt of this message, the Negotiator object requests the evaluator to 
calculate a response. This is continued until the Caller's User Agent decides to 
accept or reject the proposal. 

25 

If the response is to accept the proposal, the Callee's User Agent will send a 
message to the User Interface via the Terminal Agent to prompt the Callee to 
accept the call. If the Callee decides to accept the call, a message is sent back to 
the Terminal Agent to accept the call and this results in a 'resolution' message 
30 being sent back to the Caller's User Agent. 
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If the response is to reject the proposal, both the Caller and Callee's User Agent 
will inform their respective users that the call cannot be made and the negotiation 



will end. 



5 The following steps have made some assumptions concerning what decisions are 

made. 



14. The Caller's User Agent via the negotiator object sends a message back to the 
Callee's User Agent via its negotiator. 

10 

15. The Callee's User Agent via its negotiator calls the evaluator object to 
calculate a response. 

16. The evaluator decides to accept the counter offer. The negotiator object 
1 5 sends a message to the Terminal Agent to prompt the Callee to accept the call. 

17. 18. The Callee via the User Interface receives the message and sends a 
message back to the Terminal Agent to accept the call. 

20 19. The Terminal Agent receives the confirmation from the Callee and sends a 
message back to the Callee's User Agent via its negotiator. 



25 



20. The negotiator sends a message back to the Caller's User Agent 
negotiator object informing the User Agent that the call proposal has been agreed. 



via its 



At this point the negotiator object asks the Session object to send a message to 
the network to proceed with the connection and to prompt the Caller that the call 

setup has been agreed. 

30 It might be noted that although the "callee" will usually be a person, it could also 
be inanimate. For instance, if a user is not currently logged on, the callee will be a 
mailbox. 
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CLAIMS 



1 



A method of establishing a connection over a communications network, 
5 for service provision between first and second users of the network, there being 
provided respective connection setup means for said users, which method 

comprises: 

i) storing for each of said users data defining at least one connection 

10 configuration; 

ii) storing in respect of data defining a connection configuration for the second 
user, data defining at least one alternative connection configuration; and 

15 iii) storing in respect of said data defining a connection configuration for the 
second user, and in respect of the data defining the or each of its alternative 
connection configurations), a respective priority indicator; 

the method further comprising a negotiation process for the establishment of a 
20 connection by means of: 

iv) transmitting data defining a proposed connection configuration from the 
connection setup means for the first user to the connection set up means for the 



second user; 



25 



v) reviewing the data defining the proposed configuration at the connection 
setup means for the second user by accessing the data defining configurations and 
the respective priority indicators stored in respect of the second user; and 

30 vi) selecting and transmitting a response to the connection setup means for the 
first user, the response being determined at least in part by the result of the review 
step v) above, and selected from acceptance or rejection of the proposed 
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connection configuration, or comprising data defining a counter-proposed 
connection configuration. 

2. A method according to Claim 1 wherein the data defining at least one 
5 connection configuration comprises time data and, in the event that the response 
is acceptance of a connection configuration comprising time data, the connection 
setup means subsequently attempts to set up a connection in accordance with 
said time data. 



10 3. A method according to Claim 2 wherein said time data comprises a time of 
day and the connection setup means subsequently attempts to establish 
connection at that time of day. 

4. A method according to Claim 2 wherein said time data comprises a time 
15 interval and the connection set up means subsequently attempts to establish 

connection after said time interval has passed. 

5. A method according to any one of the preceding claims wherein, in the 
event that the response comprises data defining a counter-proposed connection 

20 configuration, the negotiation process further comprises: 

vii) reviewing the data defining a counter-proposed connection configuration at 
the connection setup means for the first user by accessing the data defining 
configurations and respective priority indicators stored in respect of the first user; 
25 and 

viii» selecting and transmitting a response to the connection setup means for the 
second user, the response being determined at least in part by the result of the 
review step vii) above, and selected from acceptance or rejection of the counter- 
30 proposed connection configuration, or comprising data defining a further counter- 
proposed connection configuration. 
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6. A method according to any preceding claim wherein steps v) through viii) 
are carried out, and repeated if necessary, until a transmitted response is 
acceptance or rejection of a proposal. 

5 7. A method according to any one of the preceding claims which further 
comprises the step of logging, by the connection setup means for each user and at 
least for the duration of a single negotiation process, received connection 
configuration proposals, any subsequent proposal transmitted by either connection 
set up means excluding proposals previously transmitted by either connection 
10 setup means. 

8. A method according to any one of the preceding claims which further 
comprises the step of storing, for each of said users, any current data relevant to 
connection setup for that user, in addition to data defining connection 
15 configurations, and the negotiation process further comprises the step of reviewing 
the additional data prior to transmission of data defining a proposed or counter- 
proposed connection configuration, and modifying the data defining a proposed or 
counter-proposed connection configuration accordingly. 

20 9. A method according to Claim 8 wherein the additional data comprises one 
or more of the following: 

a) connection mode data; 

b) location data for the relevant user with respect to the network; 

25 c) commitment data, indicating commitments previously made by the 
relevant user; and 

d) concurrent negotiation process data for the relevant user. 

10. A method according to any one of the preceding claims wherein the data 
30 defining each proposed or counter-proposed connection configuration transmitted 
from a connection setup means is selected for transmission in accordance with a 
progression from proposals with a high priority indicator towards proposals with a 
relatively lower priority indicator, for the relevant user. 
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11. A method according to any one of the peceding claims wherein each 
connection setup means can be provided for a plurality of users and wherein the 
method can be carried out concurrently by a connection setup means for more 

5 than one user. 

12. A method according to any preceding Claim, wherein each connection 
configuration comprises one or more features providing a component of a 
communications service, the features being selected from a set of features at least 

10 two of which are mutually incompatible. 

13. Apparatus for use in establishing communications connections by means 
of a communications network, the apparatus comprising: 

1 5 ') first and second network access points; 

ii) at least one data store for storing user profiles, each user profile 
comprising a set of data defining a set of connection configurations associated 
with a respective user, and for storing priority indicators in relation to the data 
defining at least two of said connection configurations; and 

20 iii) first and second connection setup means for use in establishing 
connections between said access points. 

wherein said first and second connection setup means are each provided with a 
negotiation protocol, access to at least one user profile in the data store, and 
25 means to review said priority indicators for that user profile, such that a 
communication connection can be set up between the access points, on behalf of 
at least two users, by negotiation between the first and second connection setup 
means, based on the respective user profiles and the related priority indicators. 

30 14. Apparatus according to Claim 13 wherein the data defining at least one 
connection configuration comprises a time data field and wherein at least one 
connection setup means is provided with scheduling means for scheduling 
connection setup initiation in accordance with the content of a time data field. 
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15. A method of processing data in data processing means, so as to generate 
an output signal in response to at least one input signal, wherein the input signal 
comprises at least one data element, which method comprises: 
5 i) storing a set of data elements; 

ii) allocating to each stored data element a weighting factor; 

iii) receiving said input signal; 

iv) for each data element of the input signal, searching for that data element 
in the stored set of data elements; 

10 v) for each data element of the input signal which is found by the search in 
the stored set of data elements, reviewing the weighting factor allocated to that 
data element; and 

vi) generating an output signal determined by the reviewed weighting factors. 

15 16. A method according to claim 15 wherein the review of one or more 
weighting factors comprises summing the total of the weighting factors and 
comparing the summed total with a stored value. 

17. A method of processing data according to either of claims 15 or 16, using 
20 first and second data processing means, wherein the input signal is received by the 

first data processing means from the second data processing means and the 
output signal is sent by the first data processing means to the second data 
processing means, said output signal comprising a response selected from: 
a) acceptance; 
25 b) rejection; and 

c) a signal comprising at least one data element. 

18. A method according to claim 17 wherein, in the case that the output 
signal comprises one or more combinations of data elements, together with a 

30 condition indicator, the first data processing means stores a record of said 
combinations and bars subsequent output signals by the first data processing 
means comprising any one or more of the same combinations. 
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1 9. A method according to either one of claims 1 7 or 1 8 wherein, in the case 
that the output signal comprises one or more combinations of data elements, 
together with a condition indicator which is different from the condition indicator 
of claim 18, the second data processing means generates an output signal which 
5 comprises a response selected from 

d) a signal terminating communications between the data processing means, 
and 

e) a signal consisting of any one or more of the same combinations. 

10 

20. A method according to any one of claims 16 to 19 wherein, in the event 
that the output signal comprises acceptance, the method further comprises the 
output of a control signal to control a process or apparatus. 

15 21 . A method according to either one of claims 1 6 to 19 wherein, in the event 
that the output signal comprises a signal comprising at least one data element, said 
output signal is treated as an input signal by the second data processing means 
and the second data processing means repeats the method of claim 1 5, outputting 
its output signal to the first data processing means, the method being repeated in 

20 turn by the first and second data processing means until an output signal 
comprises either acceptance or rejection. 

22. A method according to any one of claims 15 to 21 wherein the steps of 
reviewing the weighting factor allocated to each data element and generating an 
25 output signal determined by the reviewed weighting factors, comprise selecting 
from the stored data elements one or more data elements for which the combined 
weighting factors are more favourable than the reviewed weighting factor(s) and 
the output signal comprises the selected set. 

30 23. A method according to any one of claims 1 7 to 22 wherein each input and 
output signal which is transmitted between the data processing means, and 
comprises at least one data element, comprises a set of data elements which 
together define a control signal. 
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24. A method according to claim 20 and any one of claims 21 to 23 wherein 
the control signal comprises a connection setup signal for a communications 



network. 



25. A method according to claims 23 and 24 wherein the set of data signals 
which together define a control signal, define a connection configuration for use in 
the connection setup. 
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